Subject: Scott Adams Proposal for Capabilities Exchange pkt

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Wed, 11 Aug 93 16:59:05 EDT

In other words, if a node does not send a capabilities exchange, the
default is that it supports the same functions and features as in the
current RFC 1434.  Lack of support for any current functions would be
explicitly indicated, as Scott's proposal shows, e.g.

> No NETBIOS support           null  0x0004 0x0000
>
> No APPN/SNA support          bitf  0x0005 0x0004
>  for PU 2.0                                       0x00000001
>  for PU 2.1                                       0x00000002
>  for PU 4                                         0x00000004
>  etc.

I don't mean to whine, but if we all were to agree that supporting APPN
was base function for DLSw nodes, something like XID could be used for
capabilities exchanges instead of inventing something new, something like
Dave Bryant's proposal to extend APPN directory to search for non-LU
resources could be used instead of inventing something new (why don't we
merge these activities?), something like APPN route selection could be
used to determine dynamically when to bring up DLSW transport connections
instead of having the scaling problems associated with a predefined
mesh.... with HPR as the underlying transport.

Do we (the SIGmembers) really want to invest in inventing, documenting,
validating, implementing, testing....all those functions over again?
Many of us will have APPN in the same box that will be supporting
DLSW....do we really want to incur the development and storage overhead
of maintaining two "separate-but-equal" pieces of code?

Development economy --> time to market.

Marcia Peters - IBM

---

From: [email-masked] (David Matusow)
Date: Wed, 11 Aug 93 18:29:44 -0400

>
>   Date: Wed, 11 Aug 93 16:59:05 EDT
>   From: "Marcia Peters (8-444-4380)" <[email-masked]>
>   To: [email-masked]
>   Subject:  Scott Adams Proposal for Capabilities Exchange pkt
>   
    
APPN and DLSw are NOT the same thing.  They don't address the same
configuration and they don't fulfill the same requirements.  Though
it is true that it might be possible to define an intertwined
interface that uses the strengths of each for the other, the code
requirements for APPN and DLSw are vastly different.

True, many of us are looking at providing this level of support, but
making the base functionality provides one vendor a unique advantage,
as APPN is still defined by one party.  This vendor has opened
discussions from others, but this doesn't change the fact that if
one of the other vendors were to create an extension to APPN without
IBM's blessing, it would get too far.

This defacto situation requires that DLSw and APPN be kept separate.
Interoperability for SNA devices is vastly different than requiring
the use of APPN.  After all, the supported devices for DLSw are
largely the dependent resources that APPN doesn't service anyway
(though there is new architecture to handle this).  Base APPN can't
handle the transport and support of dependent LUs, yet we are
supposed to make APPN required; I don't think so.

>   of maintaining two "separate-but-equal" pieces of code?
 
As they are NOT equal, this IS required.   

>   Development economy --> time to market.

David Matusow
Hypercom